Lab 7 · 유지할 행 선택하기

UniLearn의 학적 시스템과 LMS에는 동일한 학생 ID가 없습니다. 팀은 다음과 같은 질문에 대해 각기 다른 답을 요구하는 여러 보고서를 필요로 합니다: “어떤 소스 행이 반드시 포함되어야 하는가?”

Lab 6 데이터베이스 재사용하기

Lab 6에서 이미 lab6_7_setup.sql 을 실행했다면 해당 데이터를 그대로 유지하세요. 그렇지 않다면 튜터가 제공한 공용 설정 파일을 pgAdmin에서 열고 한 번 실행하세요. 새 Query Tool 연결마다 lab6_7 을 선택하세요.

익숙한 조인부터 시작하기

다음을 확인하세요: students 및 lms_roster: 학적 ID 22개, LMS ID 6개.
Lab 6의 매칭 규칙에 따라 INNER JOIN을 실행하세요.
두 소스 모두에 존재하는 네 개의 ID를 찾아내세요.
이 결과가 어느 한쪽 소스의 완전한 목록이 될 수 없는 이유를 설명하세요.

다섯 가지 보고서 요청

공유 계정 목록 작성, 모든 학적 학생 유지, 모든 LMS 계정 유지, 두 소스 대사, 학생–과목 옵션 생성. 이러한 요청을 위해 INNER, LEFT, RIGHT, FULL, CROSS JOIN 쿼리를 작성하게 됩니다.

✍️ 빠진 맥락 예측하기

S103은 등록되어 있지만 LMS 계정이 없습니다. S901은 LMS로 가져왔지만 학적 시스템에는 없습니다. 완전한 보고서에서 각각은 어디에 속해야 할까요?

SET search_path TO lab6_7;

SELECT s.student_id AS registry_id, s.student_name,
       r.student_id AS lms_id, r.lms_name
FROM students AS s
INNER JOIN lms_roster AS r
  ON s.student_id = r.student_id
ORDER BY s.student_id;

매칭된 ID 확인하기

네 개의 행: S101, S102, S105, S121. 각 ID는 두 테이블 모두에서 고유하므로 매칭된 쌍은 각각 한 번만 나타납니다. 이 보고서에는 공유 계정만 포함됩니다.

Uma(S121)는 수강 신청이 없음에도 LMS 계정을 가지고 있습니다. 계정이 일치한다고 해서 과목 참여가 증명되지는 않습니다.

두 소스 모두 확인하기

LMS 명단은 검증되지 않은 가져오기 데이터입니다. 의도적으로 students에 대한 외래 키가 없으므로, S901과 S902는 해당 소스에만 존재할 수 있습니다.

SET search_path TO lab6_7;

SELECT student_id, student_name
FROM students
ORDER BY student_id;

SELECT student_id, lms_name
FROM lms_roster
ORDER BY student_id;

LMS ID	LMS 이름	학적 등록 여부
S101	Alice Wong	예
S102	Ben Lau	예
S105	Emma Li	예
S121	Uma Shah	예
S901	가져온 방문자 A	아니오
S902	가져온 방문자 B	아니오

공용 설정에는 이후 과제를 위한 8개 과목, 37개 수강 신청, 8개 과제, 30개 제출물도 포함되어 있습니다. 모든 레코드는 가상의 데이터입니다.

조인을 선택하기 전에 요청 읽기

요청	필요한 결과
공유 계정	일치하는 ID 쌍만.
학적 전체 범위	LMS 계정이 없더라도 모든 학적 학생.
LMS 가져오기 감사	학적 매칭이 없더라도 모든 가져온 LMS 계정.
두 시스템 대사	공유 계정과 한쪽 소스에만 있는 레코드.
과목 계획	선택된 모든 학생과 선택된 모든 과목의 조합.

Lab 6에서는 매칭된 쌍이 어떻게 행을 형성하는지 배웠습니다. 이번 Lab에서는 조인 유형을 변경하여 일치하지 않는 행을 제어하거나 모든 조합을 생성한 다음, 각 결과 행이 무엇을 나타내는지 확인하세요.